Multiple operating system control method

ABSTRACT

An inter-OS control software for switching OS&#39;s in operation executed on a single CPU is installed, and plural OS&#39;s are made alternately executed. A control program is executed exclusively on one OS, which controls the controlled apparatus. A supervisory control program and a development environment program are executed on another OS, and a memory space is divided so as to make no effect for the operation of the control program. A higher real-time performance and reliability can be established with a single CPU architecture.

CROSS REFERENCES TO RELATED APPLICATIONS

[0001] This is a continuation of application No. 09/585,120 filed Jun.1, 2000.

BACKGROUND OF THE INVENTION

[0002] The present invention relates to a control method of the controlapparatus using a digital arithmetic processor for plant instrumentcontrol and/or various machine control, and specifically, to a controlmethod for the multiple operating system in which plural operatingsystems are executed on an single processor.

[0003] In the control apparatus such as programmable logic controller(PLC) or numerical control apparatus (CNC) often used for plantinstrument control and various machine controls, procedures for controllogic are executed mainly. The functions other than procedures forcontrol logic including the function for inputting the control logicinto those control apparatus (development environment) and the functionsfor supervisory operation for the controlled status and for allowing theuser to input the data in an interactive manner (human machineinterface) are often realized by another apparatus such as personalcomputers (PC's) connected outside the control apparatus (hereinafterreferred to as user interface apparatus.) In case that those functionsare embedded in a single apparatus, those functions are executed by theindividual internal arithmetic processors. A technology related to thiskind of apparatus is disclosed, for example, in Japanese PatentApplication Laid-Open Number 9-62324 (1997).

[0004] The performance of PC's used as a user interface apparatus hasincreased, and thus, computational power can be provided so that asingle PC may cover the functions from the control logic operations tothe development environment and the supervisory control up to a certainscale of control systems. However, in case of using a control apparatuscomprising a PC-based hardware architecture supporting all of the systemfunctions and applying an operating system (OS) generally used in PC's,the operations of the programs and the device drivers other than thecontrol programs may affect the operation of the control programsthemselves.

[0005] There is such a technology that computer resources are shared incommon with multiple OS's and the functions-generic to the individualOS's are used by loading and running plural OS's on an single CPU.Examples of this technology are disclosed in Japanese Patent ApplicationLaid-Open Number 5-73340 (1993), Japanese Patent Application Laid-OpenNumber 5-27954 (1993) and Japanese Patent Application Laid-Open Number5-151003 (1993).

[0006] Privileged instructions are executed generally in OS's.Therefore, some disability occurring in one of OS's may affects theexecution of the other OS's. However, this affect is not considered inthe technology in which plural OS's are loaded and ran simultaneously ona single computer, and hence, even by means of isolating the influenceof the disabled OS over the other OS's by emulating the disabled OS bythe other OS's as described in and Japanese Patent Application Laid-OpenNumber 5-1510003 (1993), the influence may be propagated onto theoperations of both OS's in case that some disability may occur the OSemulating the disabled OS.

SUMMARY OF THE INVENTION

[0007] In the present invention, in order to solve the above problems, asoftware for controlling OS's is loaded in order to switch the executingOS's so that plural OS's may be operated alternately. The controlsoftware is made executed on the OS with higher reliability, and theuser interface program is made executed on the OS with richfunctionality, and thus, OS's, each having specific characteristics aremade executed on a single CPU. In responsive to the generation ofinterrupt or the request signal from OS's or the software programsrunning on OS's, this inter-OS control software stores and revises thecontext information of CPU operations (for example, register values ofCPU), switches the memory spaces and restarts the OS operations inanother context stored in past. In other words, the operation of therunning OS is terminated and the operation of other OS's is restarted.In addition, the inter-OS control software has a function which monitorsstart-stop operations of the running OS's and controls the start-stopoperation of the individual OS's independently. Owing to thisconfiguration, it will be appreciate that the hardware and software inthe control apparatus can be partially initialized and that the disabledpart can be automatically recovered, which leads to higher reliabilityof the total system.

[0008] Individual memory spaces occupied for the individual OS's and amemory space shared and accessible commonly by plural OS's are definedon the physical memory. Owing to this configuration, the individualmemory spaces for the kernel and the programs are so defined that theinterference among OS's such as data destruction may be avoided and thatthe necessary data may be shared by the programs each executed onthe:difference OS's. In addition, the system has such a function thatthe program running on a certain OS waits for the event issued by theother OS's and/or the programs running on those OS's and the inter-OScontrol software notifies this event. Owing to this configuration, acommunication function between the programs running on the differentOS's can be established.

BRIEF DESCRIPTION OF THE DRAWINGS

[0009]FIG. 1 is a block diagram of the embodiment using the presentinvention.

[0010]FIG. 2 is a schematic diagram of memory usage in the controlapparatus.

[0011]FIG. 3 is a flowchart showing procedures for the interruptoperation in the execution of OS-A.

[0012]FIG. 4 is a flowchart showing procedures for the interruptoperation in the execution of OS-B.

[0013]FIG. 5 is a flowchart showing procedures for the switchingoperation of OS's.

[0014]FIG. 6 is a schematic diagram showing a function for issuing andnotifying events.

[0015]FIG. 7 is a flowchart showing procedures for restarting OS-Aexclusively.

PREFERRED EMBODIMENTS OF THE INVENTION

[0016]FIG. 1 shows a bock diagram of the control apparatus in oneembodiment of the present invention.

[0017] The hardware for the control apparatus 1 comprises a centralprocessing unit (CPU) 11, a physical memory 12, a timer 14, a user inputoutput apparatus 16, a network interface apparatus 18 and a interruptcontroller 19. This structure is the same as the structure in a generalpurpose personal computer (PC). The control apparatus 1 has a networkinterface apparatus 18 connected to the network 3, and uses it forcommunicating with another control apparatus and reporting the controlresult to the host computer. The control apparatus has an input andoutput apparatus connected to the controlled apparatus 2 for exchangingsignals, and acquires the information from the controlled apparatus 2and issues the operation instruction to the controlled apparatus 2. Theinterrupt controller 19 of the control apparatus 1 relays the interruptsignal from the individual components of the control apparatus 1 to CPU11 and/or masks the interrupt signal.

[0018] The software of the control comprises an operating system A(OS-A) 21 and an operating system B (OS-B) both for the hardwareresource management and the executive control of the program running onit, an inter-OS control software 23 for switching OS-A and OS-B, asupervisory control program 2 and a development environment program 25both executed on OS-A, and a control program 26 executed on OS-B. OS-A,OS-B and the inter-OS control software 23 are operated on an single CPU11 in a privileged mode and enabled to execute all the instructionsincluding the privileged instructions for controlling CPU 11 itself. Onthe other hand, the programs running on the individual OS's are operatedin a non-privileged mode and can not execute privileged instructions.OS-A and OS-B contains device drivers operating in a privileged mode aswell as the OS kernel, and in the following, those devices are discussedso as to be unified in the OS kernel.

[0019] The input and output apparatus 12 is controlled and occupied byOS-B. On the other hand, the user input and output apparatus and thenetwork interface apparatus 18 used by the programs operated on OS-A arecontrolled and occupied by OS-A. Such a configuration is allowed thatsuch a exigency user input and output apparatus as emergency stop buttonand alarm signal output and/or such a network interface apparatus asrequiring real-time characteristics for communicating with anothercontrol apparatus may be controlled and occupied by OS-B and accessed bythe programs running on OS-B. The physical memory 13 are separated intothe area 131 for OS-A and the area 132 for OS-B. The hard wares accesseddirectly by the inter-OS control software 23 are limited to the timer 14and the interrupt controller 19.

[0020] At first, the overall operation of the software and its relationto the hardware are described. In this embodiment, OS-A is assumed to bea general purpose OS commonly used in PC's. OS-A provides sophisticateduser interfaces for the supervisory control program 24 and thedevelopment environment program 25. OS-A and the programs running onOS-A operate in the similar manner to the case that OS-B does not exist.Though the inter-OS control software 23 interrupts the operation ofOS-A, and OS-B is switched over OS-A, as the inter-OS control software23 recovers the interrupted operation of OS-A and restarts OS-A aftercompleting the operation of OS-B, it is not necessary for OS-A torecognize the existence of OS-B.

[0021] On the other hand, OS-B is assumed to be one that ischaracterized as higher real-time performance and optimized for controlprograms. OS-B yields its executive status to OS-A when the programsrunning on OS-B have no more operations to be executed (hereinafterreferred to as “idle status”.)

[0022] The inter-OS control software 23 provides functions for switchingthe execution status between OS-A and OS-B, and for communicating amongprograms on OS's. The switching operation of the execution status fromOS-A to OS-B is performed in case that i) an interrupt occurs at thehardware controlled by OS-B, ii) a pre-defined period of time has passedor iii) OS-A communicates to OS-B. The switching operation of theexecution status from OS-B to OS-A is performed only when OS-B turnsinto an idle status as described above. OS-B has always a executionstatus in preference to OS-A owing to this switching operation. Theinter-OS control software 23 operates only when the switching operationis initiated and the communication between OS's are requested, and theindividual OS's are operated independently otherwise. The privilegedinstructions to CPU 11 are issued by the individual OS's, but are notemulated by the inter-OS control software 23. It is required that theinter-OS control software 23 may operates as a part of the individualOS's so as to enable to execute privileged mode instructions every timewhen either of OS's is executed. In particular, the inter-OS controlsoftware 23 is so embedded as to operates as a device driver for OS-Awhen OS-A is executed as a general purpose OS.

[0023] As described above, hard wares are so assigned to OS-A and OS-Bas to be occupied and controlled by the individual OS's, and theoperation status of OS's are switched alternately, and the individualOS's are executed independently after the switching operation. Theinter-OS control software 23 switches the execution of both OS's andprovides the communication function between both OS's.

[0024] Next, a method for establishing the independency between OS's isdescribed. At first, a method for protecting the hard wares controlledand supervised by the individual OS from interference by another OS's.The interaction between individual hard wares and software includes theinput and output operation for the I/O addresses assigned to theindividual hard wares and the response operation of the software to theinterrupts with their interrupt numbers each assigned to the individualhard ware. Thus, the independency between OS's with respect to the hardware control is established by ensuring that the input and outputoperation to the I/O addresses assigned to the hardware controlled andmanaged exclusively by one OS and the response operation to theinterrupt number assigned to this hardware may not be executed by theother OS.

[0025] In order to specify which OS should manage and occupy theindividual hardware, the I/O address and the interrupt number assignedto the hardware are unified and stored in the interrupt table in theinter-OS control software 23. The inter-OS control software 23initialize the device driver of OS-A at the start-up of the controlapparatus 1. In its initialization process, the I/O address and theinterrupt number of the hardware for OSB are reserved and maderegistered in the interrupt table. By this process, the kernel of OS-Aand the other device drivers of OS-A recognize that the correspondingI/O address and interrupt number are occupied, and then, the operationto those hard wares by OS-A is disabled. On the other hand, by meansthat the I/O address and the interrupt number of the hardware occupiedby OS-A are made acquired by OS-B directly from the inter-OS controlsoftware 23 and registered in the interrupt table, the operation tothose hard wares by OS-B is made disabled. According to the aboveprocedures, the independency between OS's with respect to the hard warecontrol is established.

[0026] The input and output operation to the hardware is executed byOS-A and OS-B, respectively, and is not emulated by the inter-OS controlsoftware 23. Owing to this procedure, the additional overhead due to theemulation of the input and output operation can be prevented as well asthe kernel and device drivers assumed to access directly to the hardwaremay not be modified.

[0027] Nest, a method for establishing the independency of the physicalmemory space used by the individual OS's is described. The independencyof the physical memory 13 is established by defining the memory areasused separately for OS-A and OS-B, respectively The memory area usedcommonly with OS-A and OS-B is defined for sharing the data between bothOS's.

[0028] In order to define the separated areas individually occupied byOS-A or OS-B, at first, OS-A is made started when the control apparatus1 starts up, and then, the memory areas are so defined that the physicalmemory area lower than the designated address specified by the start-upoption of OS-A may be occupied by OS-A. After start-up of OS-A, OS-B ismade started by loading OS-B onto the physical memory area higher thanthe designated address. The kernel of OS-B acquires the designatedaddress recorded on the table in the inter-OS control software 23, anduses the area which is not used by OS-B under the memory management.

[0029] There are two cases for the memory area commonly shared by OS's.In one case, the memory area for the OS-A is made mapped on the addressspace for OS-B. In this case, the inter-OS control software 23 requeststhe memory management mechanism of the kernel of OS-B to add the addressof the physical memory to be shared to the logical address conversiontable (hereinafter referred to as “page table”) for the physical memoryfor OS-B and to make the physical memory correspond to the logicaladdress (hereinafter referred to as “memory mapping” or simply to“mapping”.) In the other case, the memory area for OS- is made mapped onthe address space for OS-A. In this case, the inter-OS control software23 reserves the address of the physical memory to be shared as a devicedriver of OS-A. In this case, a function of OS-A for realizing thedevice driver of the memory-mapping type physical device is used. Owingto this configuration, the kernel of OS-A maps the physical memory to beshared onto the page table for OS-A, which establishes the sharing ofthe designated common memory area.

[0030] Next, a method for establishing the independency of the logicaladdress spaces of the individual OS's is described. OS and the programsexecuted on it access to the memories with reference to logicaladdresses, and the conversion from logical addresses to physicaladdresses are automated by CPU referring to the page table. Theindividual memory management functions embedded in OS-A and OS-Boperates the page table and perform the mapping operation. At this time,by means that the page table is made separated into tables each usedexclusively by the individual OS and switched in responsive to the OS'soperation privilege, the mapping operation can be executed independentlyby the individual OS.

[0031] The page table is a table located on the physical memory, and CPUhas a register specifying the start physical address of the table. CPUobtains the address position of the page table from this register, andautomates the address conversion in responsive to the obtainedinformation. Therefore, the individual page table areas for OS-A andOS-B are defined independently on the physical memories, and the contentof the register specifying the page table position is made switched soas to specify the page table for OS switched to be enabled in the OSswitching operation by the inter-OS control software 23. Owing to thisprocedure, both OS's can operates the mapping on the individual pagetables, and thus, the independency of the logical address spaces can beestablished.

[0032] The memory usage scheme described above for the physical memoryspace and the logical address space is shown in FIG. 2. The physicalmemory space 51 is made delimited into several areas including an area52 for the kernel of OS-A, an area 54 for the OS-A programs, an area 56for the kernel of OS-B and an area 57 for OS-B programs, which are madeenabled to be accessed by the individual resources assigned to OS-A andOS-B. The logical address spaces 61 and 62 for the memories recognizedby OS-A and OS-B are independent logical address spaces corresponding tothe independent page tables of the individual OS's. When OS-A isexecuted, the physical memory spaces 56 and 57 occupied for OS-B are notmapped onto the logical address space 61. Owing to this configuration,the areas for OS-B are not accessed by OS-A with its execution enabled,which leads to preventing the data from being damaged accidentally. WhenOS-B is executed, in contrast, the physical memory spaces 52 and 54occupied for OS-A are not mapped onto the logical address space 62. Asthe inter-OS control software 23 should operates in either case of OS'salternate execution, the memory area 53 is mapped in either OS andaccessible by the programs executed on the individual OS's and availablefor exchanging data between programs executed on the individual OS's. Bymeans that the sharable area for OS-A and OS-B is limited to be used forthe programs executed in a non-privileged mode, it will be appreciatedthat the kernel and device driver for one OS is made not affected by theother OS and its programs, and the independency and reliability of theindividual OS's can be established. It is allowed that the individualarea may be made segmented and distributed for the managed unit of theaddress conversion mechanism of CPU 11 on the physical memory area 51.

[0033] According to the methods described above, the dependency of OS'scan be established.

[0034] Next, the operation of the inter-OS control software 23 isdescribed in detail. When the inter-OS control software 23 is calledexplicitly by the individual OS's or their programs and an interrupt isapplied to CPU, it is made started up. As the inter-OS control software23 is embedded as a device driver of OSA, the call by OS-A or programsexecuted on it is realized as an operation instruction directed to thecorresponding device driver (for example, IOCTL instruction). As OS-Brecognizes the existence of the inter-OS control software 23, OS-B orprograms executed on it are called as a function all from the procedurein the kernel of OS-B. As CPU 11 calls the interrupt handler byreferring to the interrupt table located on the physical memory 13 whenan interrupt occurs, all the interrupt handlers are defined as routinesin the inter-OS control software 23 by modifying the interrupt table.Owing to this configuration, the inter-OS control software 23 isactivated when any interrupt occurs, which leads to establishingadequate procedures.

[0035] Once the inter-OS control software 23 is made start up, itswitches OS's in responsive to its causal event, and performs necessaryprocedures for communicating between OS's. Its procedural steps aredescribed in detail below.

[0036]FIG. 3 shows the procedural steps for the case that an interruptoccurs while OS-A with its execution being defined with nonpriority isin operation. As the result of the interrupt input, an interruptprocessing routine of the inter-OS control software 23 is called, andthe procedures shown in FIG. 3 are executed. At first, the content ofthe register when the interrupt occurs is transferred onto the stack anda stack frame is generated (S01). Next, by referring to an interruptnumber (vector), what is judged is whether the interrupt is a softwareinterrupt or a hardware interrupt (S02). In case of the softwareinterrupt, the cause of the interrupt is either a case that an interruptinstruction is issued explicitly by the process of OS-A in operation ora case that an exception occurs due to its program operation, and ineither case, the interrupt handler of OS-A itself is called. On theother hand, in case of the hardware interrupt, which hardware makes thecause of the interrupt is judged (S03). In case that the interruptcomes. from the hardware managed by OS-A, the interrupt handler of OS-Aitself is called in the similar manner to the software interrupt. Incontrast, in case that the interrupt comes from the hardware managed byOS-B, the operation environment is switched to OS-B (S04), and then, theinterrupt handler of OS-B itself is called. In case that the interruptis a timer interrupt, the time when the interrupt occurs is identified(S05), and if the identified time is a time when the timer for OS-A orOS-B should be time up, the timer handler of the individual OS itself iscalled. In case that both timers reach the time for the scheduledtime-up, the time-up of the timer for OS-A is made withheld, and onlythe timer handler of OS-B with its execution given priority is called.

[0037]FIG. 4 shows the procedural steps for the case that an interruptoccurs while OS-B with its execution being defined with priority is inoperation. In this case, as in the similar manner to the case that aninterrupt occurs while OS-A is in operation, as the result of theinterrupt input, an interrupt processing routine of the inter-OS controlsoftware 23 is called, and the procedures shown in FIG. 4 are executed.At first, the content of the register when the interrupt occurs istransferred onto the stack (S11). Next, by referring to an interruptnumber (vector), what is judged is whether the interrupt is a softwareinterrupt or a hardware interrupt (S12). In case of the softwareinterrupt, the interrupt handler of OS-B in operation is called. In caseof the hardware interrupt, the interrupt controller 19 is made operatedwhen enabling OS-B to be in operation, and the interrupt from thehardware managed by OS-A is masked. Thus, the interrupt by the hardwaremanaged by OS-A doe not occur while OS-B is in operation. In case thatan interrupt occurs at the hardware managed by OS-B, the interrupthandler of OS-B itself is called in the similar manner to the case forthe software interrupt. However, in case that the interrupt is a timerinterrupt, the time when the interrupt occurs is identified (S14), andif the identified time is a time when the timer for OS-B should be timeup, the timer handler of OS-B itself is called. If the identified timeis a time when the timer for OS-A should be time up, the fact of theoccurrence of the time up is recorded (S15), and the operation of OS-Bis recovered. As the system has such a hardware configuration that theoperation of the interrupt controller 19 is not allowed explicitly, thecause of the interrupt is judged to be an apparatus managed by OS-A, thefact of the occurrence of the interrupt is recorded when the cause ofthe interrupt is judged (S13), and the interrupt handler of OS-A itselfmay be called when enabling OS-A to be in operation.

[0038] The above description refers to the operation in case that OS-Bis made given priority completely. In this process, the operation forswitching from OS-B to OS-A is executed only when OS-B turns into anidle state, and a process for notifying the fact of the idle state fromOS-B to the inter-OS control software 23 is called. In view of theavoidance of the deadlock when OS-B gets into an infinite loop, anoperation of OS-A is scheduled in a definite time fraction. Thus, antimer interrupt is made occur at the time other than the time when thetimers for OS-A and OS-B are count up, and OS's are switched in theinterrupt process of the inter-OS control software 23. In the inter-OScontrol software 23, the execution time for the individual OS's areestimated before hand. If a timer interrupt occurs while OS-B is inoperation, whether the time for switching from OS-B to OS-A has come isjudged by referring to the pre-defined execution time of OS-B (S16), andthen, if the time for switching to OS-A has come, OS-A is made enabledto be in operation (S17) and the procedure goes to the interrupt pointfor OS-A. If the time for switching to OS-A has not come, the procedurevisits again the interrupt point at the time when the interrupt of OS-Boccurs. In contrast, a timer interrupt occurs while OS-A is inoperation, in the procedure shown in FIG. 3, whether OS-B is staying inan idle state is judged (S06), and then, if OS-B is not in an idlestate, whether the time has passed for going back to OS-B is judged(S07). If the time has passed for going back to OS-B, OS-B is madeenabled to be in operation (S08), and the procedure goes to theinterrupt point for OS-B. However,if OS-B is staying in an idle state orthe time has not passed for going back to OS-B, then the procedurevisits again the interrupt point at the when the interrupt of OS-Aoccurs again.

[0039]FIG. 5 shows a detail procedure of switching OS's in the inter-OScontrol software 32. The OS switching procedure is invoked in case thatthe switching procedure is required in the interrupt process describedabove, that OS-B turns into an idle state or that the stand-by state ofthe stand-by program of OS-B is required to be cancelled in responsiveto the notification of the event which will be described later. Atfirst, the context at the point (hereinafter referred to as “interruptpoint”) when the interrupt occurs or the inter-OS control software 23 isinvoked is stored (S31). This means that the stack frame position wherethe content of the register in CPU11 at the interrupt point is recordedand the values of the instruction counter and the stack pointer arerecorded. Next, the property of the interrupt controller 19 is modifiedso as to apply a mask for preventing the interrupt of OS-A while OS-B isin operation or to cancel a mask for the interrupt of OS-A.

[0040] Next, the register indicating the top memory position of the pagetable is modified and the memory space is made switched (S33). Thisoperation is as same as described before. Next, the notification of theevent between OS's is executed (S34), which will be described later indetail. When switching from OS-A to OS-B, the interrupt routinecorresponding to the interrupt with its causal event recorded in stepS15 of the procedure shown in FIG. 4 is called and the suspendedinterrupt operations are made executed (S35). Then, after completing allthe recorded interrupt operations (S36), the context stored in S31 whilesuspending the interrupt operations is recovered (S38), and theprocedure visits again the interrupt point of the switched OS. All thenecessary data are stored on the memory so that the content of theregister may be deleted when OS-B is expected to be switched to OS-Awhile OS-B is staying in an idle state, and the context is made notrecovered when the interrupt handler of OS-B is called (S37).

[0041] The interrupt controller 19 can mask the individual interruptoperation by specifying its interrupt number, and in case that OS-Aoperates independently, the interrupt mask with lower priority isapplied while processing the interrupt operation of OS-A. in case thatthe masked interrupt include the interrupt of OS-B, a time day occurs inthe corresponding interrupt operation until the mask is released. Inorder to avoid this time delay, it is required to modify the interruptcontroller process in the kernel of OS-A so that the interrupt operationwith the interrupt number for OS-B may be made disabled. On the otherhand, the timer interrupt of OS-A is processed only in a definite timeinterval in responsive to the interrupt signal from the timer 14, andthus, the timer 14 is not operated while OS-A is in operation, butoperated once at the initialization process. Therefore, the interruptsignal from the timer 14 is received temporarily by the inter-OS controlsoftware 23, and it is allowed that the interrupt handler of OS-A isonly called in the steps after S03 of the procedure shown in FIG. 3.

[0042] There is such a case that the inter-OS control software 23 iscalled explicitly by either OS for the communication function between acouple of OS's. A function for issuing and notifying events between OS'sas a basic function for communicating between a couple of OS's is shownin FIG. 6.

[0043] There exists an OS-A event processing table 71 on the memorymanaged by the inter-OS control software 23. Event numbers, i1, i2, . .. iN, are assigned to the events enabled to be processed, and thereexist their corresponding N entries. The event table is empty at theinitial state. After the OS-A program (Program A) specifies the eventnumber (i2) and notifies the occurrence of the event and issues thesuspend request to the inter-OS control software 23 (S41), the inter-OScontrol program 23 records into the entry i2 of the corresponding eventon the table 71 that the program (Program A) is in a suspended state.The program issuing the suspend request stops its operation by theprogram interrupt function of OS-A. Next, if the OS-B program (ProgramB) notifies an event occurrence with its event number (iN) (S42), theinter-OS control software 23 looks up the corresponding entry iN in thetable 71 and judges the existence of the program suspended on OS-A. Incase that there is a suspended program, the release request for thesuspended program (Program B) is issued to OS-A. In responsive to thisrequest, the program suspended on OS-A is restarted and recognized thatthe suspended event is activated. The notification of event activationis allowed from the program (Program C) executed on OS-A (S44). Thus,the events issued on an identical OS and the events issued on thedifferent OS's can be made stood by simultaneously. In the similarmanner, there is an event processing table 72 for OS-B is defined, andthe event to be issued can be watched by the program on OS-B in contrastto the previous case.

[0044] The interrupt and restart function of the program used in theevent. notification described above can be realized by a function ofOS-A for reporting that the inter-OS control software 23 operating as adevice driver starts and terminates the input and output operation tothe device. For OS-B, this function can be realized by the inter-OScontrol software 23 calling a routine of OS-B for starting andterminating directly the program. Though the scope of suspend operationis assumed to be on the basis of program in the explanation of the eventnotification in the above description, the interrupt and restartoperation is applied on the thread-by-thread basis in the operatingsystems providing a multi-thread environment. Though the event processtable is defined so as to contain the program numbers, it is allowedthat it may contain the structures in OS and their pointers for judgingthe suspended programs in stead. In addition, the system is composedwith another buffer formed on the memory managed by the inter-OS controlsoftware 23, and it is operated so that the data may be received fromthe side of issuing an event and recorded onto the buffer at the sametime when the event is issued, and that the data may be transferred whenthe suspended state is released, and thus, a message communicationfunction having a function for waiting the event arrival can berealized.

[0045] The inter-OS control software 23 provides a function that allowsan continuous operation of either one of OS-A or OS-B, and interruptsand restart the other OS.

[0046] At first, what is described is an operation for terminating andrestarting OS-B while operating continuously OS-A. In case that OS-B isshut down, or that OS-B is made terminated forcibly due to an exception,a routine of the inter-OS control software 23 is called and is madenotified. As the inter-OS control software 23 does not allow OS-B to beswitched from its suspend state to being in operation from thisnotification onward, only OS-A continues to be in operation. As OS-B ismade started in responsive to a designated initialization routine calledby the inter-OS control software 23, its restart can be executed in thesimilar manner to its ordinary start-up.

[0047] Next, what is described is an operation for terminating andrestarting OS-A while operating continuously OS-B. When OS-A is shutdown, the program executed on OS-A detects the execution of shut-downoperation and notifies it to the inter-OS control software 23. When anexception occurs in OS-A, the interrupt handler of the inter-OS controlsoftware 23 judges the exception. In case that OS-A is shut down or anexception occurs, as the inter-OS control software 23 does not allowOS-B to be switched from its suspend state to being in operation, thenOS-A continues to be in operation. However, if OS-A in a suspend stateis made restarted in the similar manner to an ordinary start-up, commonhard wares including a bus shared with OS-B are initialized, which mayprevent OS-B from operating continuously. In order to solve thisproblem, a restart operation is performed in the procedure shown in FIG.7 after terminating OS-A. When an electric power is applied, OS-Ainitializes the common hard wares (S51). Then, the inter-OS controlsoftware 23 operating as a device driver is provided with a timing forinitialization process for the hard wares managed by OS-A, in which thecontext is stored (S52). In storing the context, the content of theregister and the content of all the memory area managed by OS-A arecopied on the memory area managed by the inter-OS control software 23.Then, the hard wares managed by OS-A are initialized by the individualdevice drivers of OS-A (S53). After completing this initializationprocess, OS-A goes to an ordinary operation state, and in case that OS-Ais terminated due to a shut-down operation or an exception, the inter-OScontrol software 23 shuts down only OS-A in the above described manner(S54). Then, the inter-OS control software 23 restores the contextstored at OS-A automatically or in responsive to the request from theprogram of OS-B (S55). That is, by referring to the context stored atthe initialization process (S52) for the hard wares managed by OS-A, thecontent of the memory at the initialization state is recovered and thecontent of the register is recovered, and then, the operation of OS-A isrestarted. With this procedure, as the execution of OS-A is restartedimmediately after completing the set-up of the common hard wares managedby OS-A, and OS-A can be operated in an ordinary mode after onlyinitializing the hard wares managed by OS-A, there is no need forinitializing again the common hard wares shared by OS-B.

[0048] In this embodiment, as for OS-A used as a versatile OS, only theprocess for the interrupt controller 19 is modified, and other processor components are not modified. This makes it easier to add OS-B and theinter-OS control software 23 for OS-A used as a versatile OS.

[0049] According to the present invention, when operating plural OS's ona single CPU in the control apparatus, the area of influence of theabnormal behavior of OS's and their related programs can be localized,and the abnormal state can be transferred to an ordinary operation modeonly by restarting the partial component on the basis of the individualOS's without terminating the whole control apparatus, which leads toincreasing the reliability of the system in addition, the operation ofOS's can be observed from the space independent of the spaces for theordinary operation of OS's and their programs.

What is claimed:
 1. An multiple operating system control method for amultiple operating system having a plurality of operating systemsexecuted in a digital arithmetic processor in which a first operatingsystem and a second operating system of said plurality of operatingsystems are alternately switched and executed on said digital arithmeticprocessor, wherein said multiple operating system is provided withinter-OS control software switching said first operating system and saidsecond operating system, said inter-OS control software referring to anevent processing table.